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Less of Me 

by Tim Owen 

Let's be frank, things just weren't working out. The project was a microgravity 
experiment that was supposed to be ready for launch in August 2000. Right from 
the get-go the hardware development team was behind schedule and over budget. 

The Principal Investigator (PI) and his science team had been responsible for not 
only the science but also the hardware development. This was one of the first 
projects coming out of the Microgravity office at NASA's Marshall Space Flight 
Center to use the PI mode for the bulk of the project management. "Thank you 
very much for the money. Please leave us alone." That about summed up their 
relationship with NASA. 

My management asked me to step in and get a handle on the project. On the NASA 
end of things, we'd been relatively hands off until now. The culture at Marshall is 
steeped in systems engineering, and what we had set off to do on this project was 
180 degrees opposite of that. Now we were trying to get back in the picture. The 
way my management put it to me was like this: "You've got to— you know— roll up 
your sleeves and get down in there. Take back control. You're our guy." 

I came on as the project manager for NASA in the fall of 1999. In the winter of 
2000 initial verification testing began. Right off the bat one of the key technolo- 
gies was failing. The PI needed to capture digital snapshots of the crystal growth 
process in order to understand and determine the physics of crystal growth as it 
occurs in a microgravity environment. Clarity of resolution was required at two 
different points on the crystal growth chambers: one for capturing the digital 
images, and the other for measuring the laser light scattering ratio. In the case of 
the latter, the resolution of the laser light scattering ratio was not meeting the sci- 
ence requirements. 

Such were the kinds of technical problems I was expected to get a handle on. 
There were other problems beyond the hardware developer's control. Defining 
hardware requirements, in particular hardware interfaces, was complicated by the 
fact that the development of the vehicle (Space Station) and carrier (EXPRESS 
rack) was taking place concurrently with the development of this experiment. 

If all this doesn't sound like enough high drama, it was my first assignment as a 
project manager. Naturally, I wanted to prove myself and be successful. I also 
wanted to do right by NASA and live up to the example set for me by the best 
project managers I had worked for during my twelve years at Marshall Space 
Flight Center. 
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Sometimes d^suibed as "weightlessness," microgravity is a condition in 
which the effects of gravity are greatly reduced. In microgravity, researchers 
can isolate and study the influence of gravity on physical processes, such as 
the flame shown here. 


Bull in the China Shop 

It's a precarious situation to be in when you start off riding one horse across a 
river and decide in the middle to get on another. The hardware development 
team was confused at first, and not exactly amenable to this new arrangement. 
They felt like they had been empowered to go do this job and now NASA was 
telling them, "Look, you're not meeting your cost and schedule commitments. 
We're going to have to step up our involvement." 

Suddenly their relationship with NASA, including our level of technical involve- 
ment, had changed in quite a dramatic way, in part because we were entering the 
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testing and verification phase but primarily because of their poor performance. 
There's no way you can change from one way of working together to another 
without somebody on their side wondering, "What's going on here? Am I doing 
something wrong?" 


“ Funny how natural 
tendencies, despite 
training to the con- 
trary, can undo our 
best intentions. ” 


Part of the problem was me, too. When I see that something is not going well, I 
have a tendency to push everyone out of the way and take charge. Maybe that's 
why my management thought I was the person to step in and take hold of the 
reins on this project. I had been through enough project management training to 
know the value of consensus building and the need to establish good communi- 
cation across the team. Funny how natural tendencies, despite training to the 
contrary, can undo our best intentions. Given the state of the project, the pres- 
sure I felt under, it was hard not to succumb to the urge to overcontrol. 

My objective was to stay focused on results. Schedules, deliverables. Did we pass 
that verification item, or did we fail? If we failed, what do we have to do to get back 
in line? We had some very long meetings, and there were painful discussions. In 
order to focus them on cost and schedule performance, we started each meeting 
with a schedule review. The schedule was generally about six pages long with maybe 
a dozen items on each page. As we worked through that, it became obvious to me 
that the hardware development team did not have a solid understanding of what 
was on their schedule and how it impacted other parts of the project. A lot of my 
questions started to sound the same: "Tell me what you mean by this activity." 


It was rough on them because they were seeing that they really didn't know what 
their drivers were. Not surprisingly, they developed something of a defensive pos- 
ture to me. I asked hard questions. A lot of these folks on the hardware develop- 
ment team had been going along and never been held accountable. I came in and 
one of the first things I did was say, "Let's look at who the people are on the proj- 
ect, what their responsibilities are, and hold each person accountable for what 
they're supposed to be doing.” 


Was it wrong to ask hard questions? Certainly not. But just like the impact of a 
joke depends so much on its delivery, so does the ability of a leader to effective- 
ly communicate where the team is going. My approach rubbed some people the 
wrong way. Feelings were hurt. The tone I was conveying, and none too subtly, 
was that you all are screwups and I'm here to fix things. 
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Learning What I Already Knew 

Part of establishing accountability, and being a good project manager, is learning to 
work with your team. Because every project team is only as good as the weakest link. 

I realized soon enough that I could not do everyone's position. Who knows how 
long I might have kept pushing had I not recalled a similar situation on a proj- 
ect about six years earlier? At the time I was working as a subsystems lead and 
there were some computer sequences that needed to be completed by a certain 
time. I had a particular understanding of how I thought it ought to be done, and 
when I gave the job to the person who was going to do it I said, "Have this ready 
in three weeks, and this is how I want it done." To his credit, he said to me, 
"Look, if you've given me the responsibility and you've empowered me to go do 
this, then let me do it the way I think it ought to be done." 


‘Look, if you’ve given 
me the responsibility 
and you’ve empow- 
ered me to go do this, 
then let me do it the 
way I think it ought to 
be done.’” 


That was a profound realization for me. You could even call it a "Eureka" 
moment. At that point I recalled working under project managers whom I con- 
sidered to be the best. The ones who were the best examples, my mentors, gave 
me the authority to go off and do the job my way. Because they gave me that 
authority, I felt accountable to them and to the project. 


Eventually, the guy assigned to the computer sequences worked out the problem, 
and I was glad in the end that it was not done in the way I wanted. I was able to 
see the merits of what that person was doing, and this opened up my eyes to real- 
izing that I was not alone on this project. Help was always there. All I needed to 
do was reach out to it instead of pushing it away. 


Here I was six years later, learning that same lesson all over again. You build your 
team by building your people. There was no doubt that people on this project 
were working hard. Clearly, they were not focused on being accountable for their 
cost and schedule, but there was never any question about whether they were 
putting in enough hours or doing enough analysis. 


There are ways of getting people to be accountable, and some strike me as far 
more favorable to the overall good of the project. Just like in any relationship, 
you have to try to understand each other's point of view. You can't say, "Go do 
this, just because I said it." It doesn't work that way. Milestones and accounta- 
bility are great, but the key is to agree upon goals. Once you do that you must 
let them work. You don't have the competencies of all the team members, and 
you don't have enough time to learn them all. 
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A perfect example dealt with the concurrent development of the science instru- 
ment with the vehicle and the carrier. This was a tremendously tedious and com- 
plicated task. It required an enormous amount of coordination between the hard- 
ware development team, vehicle and carrier development organizations and the 
responsible engineering disciplines at Marshall. By empowering and allowing the 
lead systems engineers to perform their roles made a big difference in the project 
running smoothly amidst the confusion. 


The significance of allowing the hardware development team, science team, and 
the engineering team and their discipline/element leads to do their jobs and 
know that I, the project manager, was going to let them to do their jobs, but with 
the expectation that they would do it in a timely manner and in a cost conscious 
way was so crucial to the ultimate success of this project. 


In the end, we were able to gain back some of our schedule after a major de-scope 
and launch date slips. More importantly, I learned something about myself, yet 
again, that is going to make me a better project manager. The bull-in-the-china- 
shop approach leaves little room for movement. There's only but two things left 
on the floor after the bull has had its way in a china shop, and neither one of 
them is very nice. 


When I came onto this project, I was very ambitious and very sure of how I 
thought things should be handled. This is going be a brand new project, starting 
my first day. Sorry, but it doesn't work that way. As much as I wanted to take 
hold of the reins, grab the bull by the horns, be active, "You do this; you do that," 
it's just not the right way. 

Question 

You can't force people to do what you want them to do. Instead, what you real- 

What lessons have you had to 
relearn throughout your career? 

ly want is to encourage people to take responsibility so that they're doing some- 
thing because they want to do it, not because you want them to do it. A little less 
of me in this case went a long way. 


Lessons 


• Resist the urge to micromanage. Encourage the team effort. Inclusion and openness 
work better than exclusion and arrogance. 


• Be open to team members who can approach a problem and solve it differently than 
you because of their expertise. 
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